The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
Large business-critical applications are complex and experience highly varying load and usage patterns. These applications are expected to provide certain service guarantees in terms of response time, throughput, uptime, and availability. At times, it may be desirable to change a system that includes such applications. Such a change might involve upgrading the system's database or modifying a configuration, for example. However, before any change is made to a production system, extensive testing and validation should be performed in a test system. In order to be confident that a change will not cause problems (e.g., errors or performance issues) in the production system once that change is introduced into the production system, a system tester should try to expose the test system to a workload that is very similar to the workload that the production system would actually experience in a real world environment.
Previous testing approaches have been inadequate because none of these previous testing approaches has been able to replicate a real production workload in a test system. According to one approach, a set of test scripts is written to test commonly executed code paths. Although this approach can be useful for performing regression testing and functional testing, this approach does not mimic a production workload. This approach usually stresses the testing system only to a very minimal extent.
Under another approach, human users are asked to use the test system as though the test system were a production system. However, this approach is very random and non-deterministic. This approach often fails to reproduce the load patterns that would be experienced in an actual production environment.
Under one possible approach, a workload from a production system may be migrated (e.g., copied) from the production system to a test system. Essentially, the session state of one or more sessions is captured on the production system and restarted on the test system. One issue that may arise in the context of a session, however, is that when a session is terminated, all data specific to that session (referred to hereinafter as “session state”) is deleted.
Depending on its size, a portion of the session state may be stored on disk rather than in memory where a majority of session state is stored. The area on disk where a portion of session state is stored is referred to hereinafter as the “temporary segment.” The portion of session state that is stored in a temporary segment is referred to hereinafter as “temporary data.” Temporary data may include temporary tables, temporary indexes created on temporary tables, and temporary large objects (LOBs). A temporary segment is not allocated of the temporary data can be stored in memory.
What is needed is a technique that accounts for temporary data in order to avoid loss of such data when a session is terminated and the associated session data is migrated to another session.